In a typical enterprise deployment, all voice related functionality is implemented at a central office. Branch offices rely on such central office functionality for performance of branch office functionality. Examples of such branch office functionality include, but are not limited to, call processing, voice messaging, interactive voice response (IVR), message on hold (MOH), and the like.
FIG. 1 shows a prior art enterprise deployment architecture for providing such central office and branch office functionalities. An enterprise deployment architecture in accordance as shown in FIG. 1 represents a normal VOIP deployment, which includes Head Quarter (HQ), Regional Head Office (RHQ) and one or more Branch Offices (BO), and a depending number of users in the particular sites. Primary and secondary call servers (CS1, CS2) are deployed in HQ and a tertiary call server CS3 is deployed in the RHQ. All the sites (HQ, RHQ, BO1, BO2) are equipped with network equipment, such as Gateways (G1-G4), each having a Voice Survivability feature provided thereon. The sites are interconnected via an Internet Service Provider network (ISP) and a Public Switched telephone Network (PSTN). An administrator will specify the priority to each call server (CS1-CS3) via a configuration function. For example, when the primary call server CS1 flaps (e.g. due to software problem in call server or connection issue), the Branch Office 1 (BO1) voice network will migrate to secondary call server CS2. As such, the secondary call server CS2 will serve all users that were previously served by the primary call server CS1. As soon as the primary call server becomes available again, all sites will migrate back to the primary call server CS1.
A deployment architecture as shown in FIG. 1 has been popularised by major VOIP venders, as it reduces overall costs of administration and maintenance. However, this deployment architecture also brings about the challenge of maintaining availability of voice services in branch offices when centralized call processing fails. Examples of such centralized call processing failures include, but are not limited to, call server connection flaps, wide area network (WAN) links fail/down, and the like.
Several prior art solutions have been offered to solve the problem of voice survivability by deploying a local proxy within enterprise deployment equipment at the branch offices. The local proxy at each branch offices monitors call servers (e.g., primary, secondary and tertiary call servers) and takes over call processing when a call processing failure takes place. While such a proxy-based solution to call survivability solves the problem of WAN link outages, it does not provide a resilient solution in the situation where a call server connection flaps periodically. In such a situation, the local proxy will keep migrating between different call servers and, even though such call servers are prone to flapping, phone connection to such call servers will continue to be made as long as the call servers are reachable. In view of connections of a call server flapping, the local proxy will continue to migrate to different call servers thereby causing adverse conditions such as dropped calls, failure in connection and the like.